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Method and system of channel resource allocation 
TECHNICAL FIELD OF THE INVENTION 

The present invention relates to transmissions and retrans- 
missions of packet data in a communications system, where 
5 the communications system uses rate switching or channel 
switching. Especially, it relates to transmissions of 
packet data and channel resource allocation in a cellular 
mobile radio system, particularly a Universal Mobile Tele- 
communications System, UMTS, or WCDMA system. 

10 BACKGROUND AND DESCRIPTION OF RELATED ART 

Retransmission of data to or from a mobile station, MS, or 
User Equipment, UE, is previously known. It is also known 
to allocate channel resources in a system using rate 
switching or channel switching. 

15 Within this patent application, a radio network controller, 
RNC, is understood as a network element including an RRM 
(Radio Resource Management) entity. The RNC is connected 
to a fixed network. Node B is a logical node responsible 
for radio transmission/reception in one or more cells 

20 to/from a User Equipment. A base station, BS, is a physi- 
cal entity representing Node B. A server device provides 
information accessible to other devices over a communica- 
tions network such as, e.g., the Internet. A client device 
is a device having access to information provided by one or 

25 more devices over a communications network. 

With reference to figure 1, base stations «BS 1» and «BS 2» 
are physical entities representing Nodes B «Node B 1» and 
«Node B 2» respectively. «Node B 1» and «Node B 2» termi- 
nate the air interface, called Uu interface within UMTS , 
30 between UE and respective Node B towards the radio network 
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controller «RNC»- «RNC» is connected to a fixed network 
«Network». The fixed network may comprise one or more 
Server Devices «Server Device». 

Medium access control, MAC, and radio link control, RLC, is 
5 used within radio communications systems like General 
Packet Radio Services, GPRS, and UMTS. 

Transport protocols, such as TCP (Transmission Control Pro- 
tocol) , are used widely for "reliable" packet data communi- 
cations, where reliability refers to its ability to handle 

10 retransmissions of data packets that are- lost during trans- 
missions and to control transmission rate based on link 
quality in terms of packet loss and delay characteristics. 
There are also protocols, such as UDP (Users Datagram Pro- 
tocol) , considered "unreliable" in the sense that they do 

15 not . themselves inherit retransmissions. 

Transport protocol packets carry packets according to 
application- level protocols such as Hypertext Transfer Pro- 
tocol (HTTP) . 

International Patent Application W09965219 discloses a 
20 TCP/IP/PPP modem including an HTML packet sniffer. The HTML 
packet sniffer interprets the packet header to determine if 
the data content contains valid HTML data. If so, an HTML 
rating decoder begins to parse the HTML data for rating 
tags. An HTTP response parser interprets an HTTP header. 

25 The Internet Society: Request for Comments (RFC) No. 2616, 
June 1999 describes Hypertext Transfer Protocol 1.1 (HTTP 
1.1). Sections 4 . 4 and 14 . 13 describe determination of 
message length. 

The Internet Society : Request for Comments (RFC) No. 3135, 
30 June 2002 describes proxy solutions for some explicitly 
mentioned systems, including systems operating with TCP for 
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communication links being subject to small bandwidth-delay 
products, such as W-LANs (Wireless Local Area Networks) , W- 
WANs (Wireless Wide Area Networks) and GSM (Global System 
for Mobile Communications) or links optimized with small 
5 block error rates (BLER) , such as satellite links. 

U.S. Patent US5673322 describes a split proxy system that 
encapsulates TCP/IP transmissions into a script transmis- 
sion. 

European Patent Application EP1109359 describes an appara- 
10 tus and method for dividing a TCP connection into two con-.' 
nections, having congestion control in only one of the two 
connections . 

3 rd Generation Partnership Project (3GPP) : Technical Speci- 
fication Group Radio Access Network, Radio Interface Proton 
15 col Architecture, 3GPP TS 25.301 v3.6.0, France, September 
2000, describes an overall protocol structure of a Univer- 
sal Mobile Telecommunications System (UMTS) . There are 
three protocol layers: 

- physical layer , layer 1 or Ll, 

20 - data link layer, layer 2 or L2, and 

- network layer, layer 3 or L3 . 

Layer 2, L2 , and layer 3, L3 are divided into Control and 
User Planes. Layer 2 consists of two sub-layers, RLC and 
MAC, for the Control Plane and four sub-layers, BMC, PDCP, 
25 RLC and MAC, for the User Plane. The acronyms BMC, PDCP, 
RLC and MAC denote Broadcast /Multicast Control, Packet Data 
Convergence Protocol, Radio Link Control and Medium Access 
Control respectively. 

Figure 2 displays a simplified UMTS layers 1 and 2 protocol 
30 structure for a Uu Stratum, UuS, or Radio Stratum, between 
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a User Equipment UE and a Universal Terrestrial Radio Ac- 
cess Network, UTRAN. 

Radio Access Bearers, RABs, are associated with the appli- 
cation for transportation of services between core network, 
CN, and User Equipment, UE, through a radio access network. 
.Each RAB is associated with quality attributes such as 
service class, guaranteed bit rate, transfer delay/ resid- 
ual BER, and traffic handling priority. An RAB may be as- 
signed one or more Radio Bearers, RBs, being responsible 
for the transportation between UTRAN and UE. For each mo- 
bile station there may be one or several RBs representing a 
radio link comprising one or more channels between UE and 
UTRAN. Data flows (in the form of segments) of the RBs are 
passed to respective Radio Link Control, RLC, entities 
which amongst other .tasks buffer the received data seg^ 
ments. There is one RLC entity for each RB. In the RLC 
layer, RBs are mapped onto respective logical channels. A 
Medium Access Control, MAC, entity receives data transmit- 
ted in the logical channels and further maps logical chan- 
nels onto a set of transport channels. In accordance with 
subsection 5.3.1.2 of the 3 GPP technical specification MAC 
should support service multiplexing e.g. for RLC services 
to be mapped on the same transport channel. In this case 
identification of multiplexing is contained in the MAC pro- 
tocol control information. 

Transport channels are finally mapped to a single physical 
channel which has a total bandwidth allocated to it by the 
network. In frequency division duplex mode, a physical 
channel is defined by code, frequency and, in the uplink, 
relative phase (I/Q) . In time division duplex mode a 
physical channel is defined by code, frequency, and time- 
slot. As further described in subsection 5.2.2 of the 3GPP 
technical specification the Ll layer is responsible for er- 



WO 03/065739 




CT/SE03/00176 



ror detection on transport channels and indication to 
higher layer, FEC encoding/decoding and interleav- 
ing/deinterleaving of transport channels . 

PDCP provides mapping between Network PDUs (Protocol Data 
Units) of a network protocol, e.g. the Internet protocol, 
to an RLC entity. PDCP compresses and decompresses redun- 
dant Network PDU control information (header compression 
and decompression) . 

None of the cited documents above offers a method and sys- 
tem of retrieving channel resource requirements in systems 
using channel resource management, involving rate switching 
or channel switching, allowing for identical or same- type 
transport or application-level protocols for fixed and 
switched rates/channels. Nor do they provide an interface 
to channel resource management. 

SUMMARY OF THE INVENTION 

A system according to prior art includes buffering of data 
in a Radio Network Controller. This causes delay and 
round-trip time latency. I.e., the time for a user or user 
application to perceive a response to transmitted, data or 
undertaken action from the receiving end is not immediate, 
but should be kept as small as possible. 

With systems using channel resource management, such as ra- 
dio resource management in UTRAN it is greatly desirable, 
however difficult to achieve, a method and system where 
channel resource can be allocated in a best match «to data 
objects to be transferred over the channel introducing no 
or negligible additional delay. 

Buffering of data for predictions causes delay of (one-way) 
data destined for a User Equipment. Protocols originally 
designed for wireline transmission, e.g. TCP (Transmission 
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Control Protocol) , can introduce further delay due to use 
of congestion algorithms behaving as if the channel were 
congested if not properly managing channel resources. 

For data transmissions over link protocols with relatively 
5 small buffer sizes, evaluation of the need for capacity of 
existing connections and allocation of capacity to new con- 
nections for best- fit matching of data requirements are 
difficult or impossible. 

Consequently, it is an object of this invention to increase 
10 utilization of channel resources of a channel switching 
system. 

It is also an object of this invention to eliminate or re- 
duce delay and latency as perceived by a user. 

A related object is to reduce delay and latency as per- 
15 ceived by a congestion control algorithm with applications 
such as Internet connections over a radio link in a WCDMA 
(Wideband Code Division Multiple Access) system. 

A further object is to enable or simplify allocation and 
management of capacity to new and existing connections, in- 
20 eluding evaluation and prediction of capacity needs for 
various connections. 

Finally, it is an object to accomplish the above mentioned 
objects without requiring interference of or operations on 
layer 3 semantics. 

25 These objects are met by the invention, which is particu- 
larly well suited for a Universal Mobile Telecommunications 
System, UMTS, providing an interface between a sniffer de- 
vice and channel resource management, particularly radio 
resource management. 
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Preferred embodiments of the invention, by way of examples, 
are described with reference to the accompanying drawings 
below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows communication between a UE and a base sta- 
tion involved in a connection between an RNC and the UE. 

Figure 2 displays a layered protocol structure, according 
to prior art, in a radio communications system. 

Figure 3 displays a first embodiment for radio resource' 
control, according to the invention. 

Figure 4 illustrates schematically a second embodiment for 
radio resource control, according to the invention. 

Figure 5 displays a third embodiment for radio resoiirce 
control, according to the invention. 

Figure 6 shows a fourth embodiment for radio resource con- 
trol, according to the invention. 

Figure 7 shows a stand-alone sniffer sniffing data re- 
quests in uplink direction or data responses in downlink 
direction, according to the invention. 

Figure 8 illustrates a sniffer sniffing data requests in 
uplink direction or data responses in downlink direction 
integrated with RNC, according to the invention. 

Figure 9 illustrates a sniffer sniffing data requests in 
downlink direction or data responses in uplink direction, 
according to the invention. 

Figure 10 illustrates a sniffer sniffing data requests in 
downlink direction or data responses in uplink direction 
integrated with RNC, according to the invention. 
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Figure 11 shows a block diagram with a stand-alone sniffer 
sniffing data requests in downlink direction or data re- 
sponses in uplink direction connected to a User Equipment, 
according to the invention. 

5 Figure 12 illustrates an exemplary sniffer sniffing data 
requests in downlink direction or data responses in uplink 
direction integrated with a User Equipment, according to 
.the invention. 

Figure 13 shows a block diagram with a stand-alone sniffer 
10 sniffing data requests in uplink direction or data re- 
sponses in downlink direction connected to a User Equip- 
ment, according to the invention. 

Figure 14 illustrates an exemplary sniffer sniffing data 
requests in uplink direction or data responses in downlink 
15 direction integrated with a User Equipment, according to 
the invention. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

As an example illustrating the fundamentals of the inven- 
tion consider a User Equipment «UE/Client Device» of figure 

20 1 requesting data from a network server «Server Device», 
responding by transmitting the requested data. In most 
application-level protocols the data request or the data 
response includes inf ormation on size of the requested data 
object. This information is passed through radio network 

25 controller «RNC» and base station «BS 2 /Node B 2». As a 
non-exclusive example, the specification of HTTP 1.1, 
widely used in the Internet, specifies the header of a re- 
sponse to a data request to comprise such information. 
This information is of great value for management of 

30 strictly limited channel resources between base station 
«BS 2 /Node B 2» and User Equipment «UE/Client Device». 
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Retrieval of data object size included as one or more data 
packet elements can be achieved by passing packet data 
through or by a processing entity identifying or recogniz- 
ing the relevant one or more data packet elements as they 
5 appear, in the sequel denoted as sniffing. 

Figure 3 displays a first embodiment for radio resource 
control, according to the invention. A «Packet Data 
Server», e.g. a Web Server corresponding to «Server Device» 
of figure 1, transmits data packets to a User Equipment 
10 «UE» being client device. 

Data packets «Packet 1», «Packet 2», «Packet 3», «Packet 4» 
are transmitted from the Packet Data Sender through a net- 
work to a Radio Network Controller. In accordance with 
UTRAN technical specifications, RNC includes an RLC proto- 

15 col layer, as schematically illustrated in figure 2. «RNC» 
communicates with User Equipment «UE 1», «UE 2». The RNC 
comprises Radio Resource Management «RRM» undertaking radio 
resource control, assigning and switching channel re- 
sources. According to prior art, RRM relies on local traf- 

20 fic measurements in «RNC» and there are only limited means 
for distinguishing different traffic or data dependent 
needs for channel resources of different connections of ! the 
RNC. There is a sender-receiver relationship between «RNC» 
and «UE 1» and «UE 2», respectively. Packets transmitted 

25 from RLC protocol entity residing in RNC are acknowledged 
by User Equipment «UE 1», «UE 2». The sender-receiver re- 
lationship is subject , to latency due to a round- trip delay 
between RNC and User Equipment «UE1», «UE2» included in the 
end-to-end round-trip delay time «RTT» as indicated in f ig- 

30 ure 3. Assuming that User Equipments «UE 1», «UE 2» are 
using an application making use of e.g. HTTP over TCP, such 
as web browsing, the Packet Data Sender «Data Sender» the 
transmits exemplary HTTP packets in TCP packets to be ac- 



WO 03/065739 




•CT/SE03/00176 



knowledged by the respective client devices «UE 1», «UE 2». 
To avoid confusion, "application protocol acknowledgements" 
refer to acknowledgements associated with the L3 network 
layer and °RLC acknowledgements" refer to acknowledgements 
5 associated with the L2/RLC protocol layer. As the applica- 
tion protocol acknowledgements and the RLC acknowledgements 
are nested, the application protocol acknowledgments will 
perceive an increasing round-trip time delay as the RLC ac- 
knowledgements round-trip time increases . 

10 As a user moves with his User Equipment away from a base 
station «BS 1» towards another base station «BS 2» in fig- 
ure 1, the connection between UE and RNC is likely to be 
rerouted from being over a first Node B «Node B 1» to being 
over a second Node B «Node B 2» or over both «Node B 1» and 

15 «Node B 2» using soft handover. In figure 1, the base sta- 
tions are connected to the same radio network controller 
RNC. However, the invention also covers the exemplary 
. situation where the base stations are connected to differ- 
ent RNCs. In UMTS, the RLC protocol is terminated in a 

20 serving RNC, SRNC, responsible for interconnecting the ra- 
dio access network of UMTS to a core network. 

An aspect of the invention is that according to prior art 
there is a risk of radio resources being underutilized and 
users experiencing increased latencies and delays or even 
25 the connection being broken. There is also a risk for the 
■transfer from the data provider to stall. 

In UMTS, existing RLC protocols operate with limited buffer 
sizes. One reason for this is delay constraints. Accord- 
ing to prior art data throughput and buffer status measure- 
30 ments provide very limited information on the future band- 
width needs of a connection. Buffer fill level and data 
throughput measurements provide no means to distinguish 
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whether the packets presently loading the link are the last 
few of a transfer, or if there remains a lot of data at the 
sender still to be transmitted. Consequently, evaluation 
of data-related need for capacity of existing connections 
5 and allocation of capacity to new connections are difficult 
or impossible. There is no information in RLC buffer on 
how large objects a client is retrieving from the Packet 
Data Sender, e.g. downloading, to estimate a user's near- 
future need, associated with the data he is retrieving, for 
10 channel capacity. 

As a non-exclusive example illustrating a problem of prior 
art, RRM may perform a channel up-switch, allocating more 
channel capacity to a connection, at a moment when the last 
bits of a data transfer have been transmitted leading to 
15 waste of channel resource of no value to the user obtaining- 
data bandwidth increase, reducing the data bandwidth avail- 
able to other connections of a scarce shared channel re- 
source . 

The problem cannot be solved by increasing RLC buffer size, 
20 as long as the RLC buffer is part of an end-to-end-delay of 
a connection between a data provider and an end user, where 
the data provider awaits application protocol acknowledge- 
ments from the user, since increasing RLC buffer size would 
introduce additional delay and require extensive time-out 
25 limits. 

Another aspect of the invention, related to problem in 
prior art, is evaluation when there is a plurality of on- 
going connections. It is difficult or impossible for the 
channel resource management, such as RRM (Radio Resource 
3 0 Management) in UMTS, to evaluate which connection or con- 
nections of a plurality of active ones that is in need for 
more capacity or bandwidth. 
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An advantage of introducing a sniffer according to the in- 
vention is that the needs of individual users /clients can 
be predicted or information on future needs be retrieved 
before the need appears, in contrast to prior art. From 
.5 information on object sizes channel resources can be appro- 
priately allocated according to the needs as predicted or 
retrieved. 

A problem related to a transport protocol such as TCP and 
channel switching is that sudden buffer drainage in RLC 

10 buffer, or corresponding prior art buffer, or low through- 
put * due to, e.g., TCP loss recovery or great variations in 
packet delays may trigger unwanted channel down switch if,< 
e.g., channel resource management interprets data transmis- 
sions to have ended notwithstanding a lot of data remain to 

15 be sent from the data provider. A straightforward solution 
•to avoid channel down- switching is to have extensive pro- 
. hibit time delays prohibiting channel down- switching during 
a predefined time frame beginning at the first instance of 
indication of a broken connection or a connection with less 

20 need for capacity. However, such a solution would be inef- 
ficient in a channel resource perspective, prohibiting 
other connections to access channel resources of truly bro- 
ken connections during the prohibit time frame, leaving 
scarce channel resources underutilized. 

25 The present invention provides a solution also to this 
problem. Interfacing the data provider in close relation 
to channel resource management, such as RRM in UMTS, en- 
ables the data provider to proceed data transmissions. 
This will prevent data transmissions from getting stalled 

30 due to channel resources being poorly distributed to the 
various data streams, allowing for improved prediction of 
channel capacity to allocate. Consequently , prohibit time 
frames for channel down switching can be reduced or elimi- 
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nated, increasing utilization of scarce channel resources, 
such, as radio channel resources. 

The present invention provides for efficient channel 
switching and good radio resource utilization of particu- 
5 larly a UMTS system, but also applies to other systems us- 
ing packet services such as GPRS, enabling reliable predic- 
tions of future bandwidth needs of connections close to ra- 
dio resource management, generally located in RNC. 

Figure 4 illustrates schematically a second embodiment for 

10 radio resource control according to the invention. Figure 
4 corresponds in a plurality of aspects to figure 3. Data 
packets «Packet 1», «Packet 2», «Packet 3» and «Packet 4» 
are transmitted from a Packet Data Sender. The data pack- 
ets destined for User Equipments «UE 1», «UE 2» are routed 

15 by radio network controller «RNC». Data is passed through 
a sniffer device «Sniffer» comprising at least one sniffing 
entity «Sniff A», «Sniff B», sniffing data streams passing 
through «RNC» and «Sniffer» for information on data object- 
size(s) . In figure 4, and also in figure 3, signaling 

20 «Meas» carrying information revealing size of data ob- 
ject (s) for reserving and allocating channel resources cor- 
responding to revealed data object size(s) is transferred 
«Meas» from the sniffer device «Sniffer» to radio resource 
management «RRM». Channel allocation is determined by ra- 

25 dio. resource management, RRM, depending on estimated re- 
source . requirement as indicated by signaling «Meas» from 
device «Sniffer» to RNC-entity «RRM». The signaling can be 
transferred individually for each sniffing entity, 
«Sniff A», «Sniff B» or collectively for a plurality of 

30 sniffing entities in sniffer device «Sniffer». In figure 
4, the sniffer entity «Sniff A», «Sniff B» is included in a 
stand-alone unit «Snif fer», connected to a radio network 
controller «RNC», whereas in figure 3 the one or more 
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sniffing entities «Sniff A», «Sniff B» are included in 
«RNC» - 

Figures 5 and 6 display a third and forth embodiment, re- 
spectively, for radio resource control, according to the 
5 invention. According to the third and fourth embodiments, 
the sniffer comprises buffers of sizes sufficiently large- 
to store objects of data, in their entirety or in part, to 
be transmitted to the client. The sniffer solution does 
not exclude splitting the application protocol connection 

10 between «Packet Data Sender» and client «UE 1», «UE 2» into 
two parts. This is the case for the embodiment in figures 
5 and 6, with the sniffer in a stand-alone device connected 
to RNC and in figure 6, where it is integrated in RNC. 
Again, data in one direction, particularly downlink direc-' 

15 tion, is sniffed for information on block-sizes, e.g. HTTP 
content-length, to be used for radio resource management in 
«RRM» . Block-size data is transferred «Meas» from «Snif- 
fer>> to «RRM» . 

A particular advantage is achieved if a connection such as 
20 a TCP-connection is split into sub-connections, acknowledg- 
ing correctly received data packets, for an individual sub- 
connection, thereby reducing round- trip time latency and 
jitter. 

Buffered data can be made further use of to predict the 
25 need for channel resources to transmit the data packets of * 
the objects. Thereby, reliability and timeliness of radio 
resource control, based upon data from «Sniffer» can be 
further increased. 

In the fourth embodiment of figure 6, the buffers of the 
30 sniffer are made use of also for RLC buffering. Figures 3, 
4 and 5 are illustrated to comprise dedicated RLC buffers 
for this purpose. 

14 



WO 03/065739 




CT/SE03/00176 



Figure 7 shows a block diagram with a stand alone sniffer 
unit «Sniffer» connected to a universal terrestrial radio 
access network <<UTRAN>>, according to the invention. The 
sniffer includes one or more sniffing entities «Sniff», 
5 sniffing data requests «Req» in uplink direction, data re- 
sponses «Data» in downlink direction or both- A data 
sender «Data Sender» transmits upon request «Req» data 
«Data» destined for a user of a User Equipment «UE» in a 
communications system including an exemplary universal ter- 

10 restrial radio access network «UTRAN» providing data for 
«UE». Universal terrestrial radio access network «UTRAN» 
sends data «Data» to User Equipment «UE» over a switched 
channel. User Equipment «UE» acknowledges received data, 
positively or negatively. Data from «Data Sender» is re- 

15 ceived and is optionally acknowledged «Ack» in a data re- 
ceiver «DataRec» in «Sniffer». In the case of sniffer ap- 
plication protocol acknowledgements, received data is 
cached or stored in a data buffer «Buffer» in «Sniffer». 
The buffered data is used for determining data related to 

20 radio resource allocation «Meas», e.g. block-size data, for 
radio resource management «RRM» in UTRAN. Data is trans- 
ferred from «Sniffer» to its destination «UE» on a switched 
channel as established by UTRAN. In the case of sniffer 
.application protocol acknowledgements, UE acknowledges "re- 

25 ceived data towards the sniffer in place of data sender. 
Upon reception of such application protocol acknowledge- 
ment, data need not be stored any further for the acknowl- 
edging destination and is preferably released from 
«Buf f er». 

30 The invention does not require separate application proto- 
col acknowledgements by sniffer, interfering layer 3 seman- 
tics or breaking an end-to-end link. Thereby, the sniffer 
can be made more or less insensitive to e.g. associated 
problems related to handover of buffer content. 
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Irrespective of whether or not data is acknowledged by 
«Sniffer», it sniffs data for information on link require- 
ments. Measurements «Meas» on link requirements forming a 
basis for radio resource allocation are transferred from 
5 «Sniffer» to radio resource management «RRM». Data re- 
quested by UE is transferred to data sender via «UTRAN» . 
Preferably, the sniffer forms part of an extended UTRAN. 

Figure 8 illustrates a performance enhancing proxy «Snif- 
fer», according to the invention, integrated with radio 

10 network controller «RNC», being part of «UTRAN» in an exem- 
plary WCDMA system. As with figure 7, also the sniffer 
device «Sniffer» in figure 8 sniffs data requests «Req» in 
uplink direction, data responses «Data» in downlink direc- 
tion or both. Transmissions and devices are similar to 

15 those of figure 7, labeled correspondingly. 

Figure 9 shows an embodiment of the invention sniffing data 
requests «Req» in downlink direction, data responses «Data» 
in uplink direction or both. The sniffer «Sniffer» com- 
prises one or more sniffing entities «Sniff» for sniffing 

20 data requests «Req» or data responses «Data». Depending on 
sizes of data objects, radio resource management «RRM» al- 
locates radio resources of a switched channel. Of course, 
the sniffers of figure 7 and 9 can be incorporated into one 
single sniffer entity sniffing requests in both downlink 

25 and uplink directions- As for figure 7, also the sniffer 
of figure 9 preferably forms part of an extended UTRAN. 

Figure 10 shows an embodiment with «Sniffer», corresponding 
to «Sniffer» of figure 9, integrated in radio network con- 
troller «RNC» of «UTRAN». Entities corresponding to those 
30 of figure 9 have been labeled correspondingly. 

Figure 11 shows a block diagram with a stand-alone sniffer 
unit «Sniffer» connected to a User Equipment «UE» according 

16 



WO 03/065739 




'CT/SE03/00176 



to the invention. The sniffer, sniffing data requests 
«Req» in downlink direction, data responses «Data» in 
uplink direction or both, can be connected to User Equip- 
ment «UE» on Data Sender side or on UTRAN side of User 
5 Equipment «UE». A data sender «Data Sender» transmits data 
destined for a Data Receiver or Server Device (not included 
in the figure) in a network behind an exemplary universal 
terrestrial radio access network «UTRAN» over a switched 
channel as established by UTRAN. 

10 A data receiver «DataRec» in the sniffer device «Sniffer» 
receives data from «Data Sender». The sniffer device 
«Sniffer» can optionally acknowledge «Ack» data received 
from «Data Sender», positively or negatively. For this 
case, received data is cached or stored in an optional data 

15 buffer «Buffer», as described in relation to figure 7. 

Data requests «Req» or data responses «Data» passed through 
the. sniffer are analyzed for size of requested objects. 
Optionally buffered data may be used for further measure- 
ments or extraction of prediction data.- Data on requested 

20 object sizes and optionally further measurements or predic- 
tion data «Meas» is transferred to radio resource manage- 
ment «RRM» in UTRAN. Prediction data «Meas» is transferred 
from «UE» to «UTRAN» on a switched channel as established. 
This can be identically the same channel used for payload, 

25 as well as another channel- However, for reasons of sim- 
plicity, a separate dashed line between «Sniffer» and «UE», 
and a single dashed line from «UE» to «UTRAN» indicate the 
transfer. Radio resource management data «RRinfo» for rate 
and channel selection is transferred from «UTRAN» to «UE» 

30 on a downlink channel. For reasons of clarity this is in- 
dicated by a separate dashed line between «UTRAN» and «UE». 
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Figure 12 illustrates an exemplary sniffer device «Sniffer» 
according to the invention. The sniffer, sniffing data re- 
quests «Req» in downlink direction, data responses «Data» 
in uplink direction or both, is integrated with a User 
5 Equipment «UE», preferably a User Equipment of a WCDMA sys- 
tem- Transmissions and devices are similar to those of 
figure 11 labeled correspondingly. 

Also requests for data in uplink direction and their re- 
sponses in downlink direction can be analyzed by a sniffer 
10 associated with a User Equipment, if appropriate. 

Figure 13 shows a block diagram with a stand-alone sniffer 
unit «Sniffer» being connected to a User Equipment «UE» ac- 
cording to the invention. The sniffer, sniffing data re- 
quests in uplink direction, data responses in downlink di- 

15 rection or both, can be connected to User Equipment «UE» on 
Data Sender side or on UTRAN side of User Equipment «UE». 
A data receiver «Data Receiver» receives data from a Data 
Sender or Server Device (not included in the figure) in a 
network behind an exemplary Universal Terrestrial Radio Ac- 

20 cess Network «UTRAN» over a switched channel as established 
by UTRAN. 

Data requests or data responses passed through the sniffer 
are analyzed for size of data objects. Data on object 
sizes and optionally further measurements or prediction 

25 data «Meas» is transferred to radio resource management 
«RRM» in UTRAN. Prediction data «Meas» is transferred from 
«UE» to «UTRAN» on a switched channel as established. This 
can be identically the same channel used for payload, as 
well as another channel. However, for reasons of simplic- 

30 ity, a separate dashed line between «Sniffer» and «UE», and 
a single dashed line from «UE» to «UTRAN» indicate the 
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transfer. Radio resource management allocates channel re- 
sources in «UTRAN» . 

Figure 14 illustrates an exemplary sniffer device «Sniffer» 
according to the invention. The sniffer, sniffing data re- 
5 quests in downlink direction, data responses in uplink di- 
rection or both, is integrated with a User Equipment «UE» / 
preferably a User Equipment of a WCDMA system. Transmis- 
sions and devices are similar to those of figure 13 labeled 
correspondingly . 

10 Of course, various combinations of sniffing entities 
«Sniff» of figures 7—14 can be combined to achieve an in- 
terface to radio resource management sniffing uplink and 
downlink directions in different entities. A particular 
'advantage of the invention is that sniffing of both uplink 

15 and downlink directions can be accomplished in one single 
sniffer device, e.g. located in RNC. 

Preferably, all retransmission entities, interconnecting 
networks or channels of different characteristics, e.g. 
RNCs in UMTS, operate according to the invention for out- 
20 standing performance. However, the invention can also be 
used in systems also including retransmission entities, 
such as RNCs, not operating according to the invention. 

A person skilled in the art readily understands that the 
receiver and transmitter properties of a BS or a UE are 

25 general in nature. The use of concepts such as BS, UE or 
RNC within this patent application is not intended to limit 
the invention only to devices associated with these acro- 
nyms. It concerns all devices operating correspondingly, 
or being obvious to adapt thereto by a person skilled in 

30 the art, in relation to the invention. As an explicit non- 
exclusive example the invention relates to mobile stations 
without a subscriber identity module, SIM, as well as user 
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equipment including one or more SIMs. Further, protocols 
and layers are referred to in close relation with UMTS and 
Internet terminology. However, this does not exclude ap- 
plicability of the invention in other systems with other 
5 protocols and layers of similar functionality. 

The invention is not intended to be limited only to the em- 
bodiments described in detail above. Changes and modifica- 
tions may be made without departing from the invention. It 
covers all modifications within the scope of the following 
10 claims. 
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